在 Cloud Architect / Pre-sales 的工作中，收到的需求通常不會是一份完整的技術規格，更多時候只有一句話：

「海外使用者連線很慢，希望可以改善。」

「這套系統不能中斷，還要有異地備援。」

「公司之後會有很多 AWS 帳號，權限和網路要怎麼管理？」

這些資訊可以讓我知道客戶想解決的大方向，卻還不足以直接決定架構。

例如，聽到「海外連線很慢」，可能會想到 CloudFront、Global Accelerator 亦或是 Route 53，但如果還不知道流量使用什麼協定、內容能不能快取、使用者分布在哪裡，其實很難判斷哪個服務比較合適。

同樣地，「不能中斷」也不代表一定要做 Multi-Region，還需要確認系統最多可以中斷多久、能接受遺失多少資料，以及發生故障時是否可以人工切換，這些條件會影響最後選擇 Multi-AZ、備份還原、Pilot Light，還是更完整的跨區域架構。

先釐清需求，再選 AWS 服務

面對新的需求時，我通常會先從幾個方向確認：

• 系統提供什麼功能，使用者和流量分布在哪裡？
• 可接受的中斷時間與資料遺失範圍是多少？
• 是否有資料加密、私有連線或法規要求？
• 現有環境要如何與 AWS 連接或遷移？
• 團隊願意承擔多少部署與維運工作？
• 預算、時程及未來擴展需求是什麼？

這些問題不一定能在第一次討論就全部得到答案，但可以先找出哪些是必要條件、哪些只是偏好，以及哪些資訊仍需要確認。

服務選型也不只是比較功能，某個方案即使做得到，仍要考慮後續如何部署、監控、備份、升級和處理故障。有些受管服務費用較高，卻能減少日常維運；有些自建方案控制能力較完整，但團隊也要承擔更多管理責任。

因此，架構設計很少有所謂的唯一正解，比較實際的做法，是根據目前的需求與限制選擇合適的方案，並清楚說明接受了哪些取捨。

AWS 的 Well-Architected Framework 也採用類似的思路，從營運卓越、安全性、可靠性、效能效率、成本最佳化與永續性等面向檢視架構，而不是只看服務能否正常運作。

接下來的 30 天

接下來，我會從多帳號治理、IAM、網路、資料庫、儲存、災難復原、容器、遷移、自動化與成本等主題，整理常見 AWS 服務之間的選型差異。

每篇文章會盡量回答三件事：

1. 這項需求真正要解決什麼問題？
2. 哪些條件會改變服務選擇？
3. 選擇之後，要承擔哪些限制與維運責任？

內容會以 AWS 官方文件為基礎，並視主題加入小型實作、架構圖或情境推演，希望這 30 天最後整理出來的內容，不只是 AWS 服務介紹，而是一套面對需求時可以重複使用的選型思路。